Clarify positional argument handling in TypedDict constructor#2248
Clarify positional argument handling in TypedDict constructor#2248BHUVANSH855 wants to merge 9 commits intopython:mainfrom
Conversation
… conformance tests
|
Just checking in regarding the latest updates to this PR. Thank you! |
|
I am not convinced that we should discourage type checkers from accepting additional forms. |
Thanks for the feedback @carljm, I’ve updated the wording to remove the restriction on additional positional forms and instead clarify that only the specified behavior is required, while type checkers may choose to support additional forms. Please let me know if this looks good now. |
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
Thanks. I'm generally fine with this leave-it-up-to-type-checkers approach; it's good to add something to the spec text to make it more explicit, even if we don't strictly require a particular behavior. Would like to know what @JelleZijlstra and others think.
| whose type is a TypedDict. In this case, the resulting value is initialized from | ||
| that argument. | ||
|
|
||
| Type checkers may choose to accept additional forms of positional arguments, |
There was a problem hiding this comment.
| Type checkers may choose to accept additional forms of positional arguments, | |
| Type checkers may choose to accept additional forms of positional arguments, and/or mixed positional/keyword calls, |
There was a problem hiding this comment.
Thanks for the feedback! @carljm
I initially added wording to clarify that type checkers may accept additional positional forms, but based on the discussion, I’ve simplified the spec to avoid implying specific behavior beyond what is clearly supported.
For now, the spec only describes the keyword-based constructor and the case of a single TypedDict positional argument, without constraining or explicitly encouraging other forms.
Happy to refine this further if we reach consensus on specific patterns that should be required.
JelleZijlstra
left a comment
JelleZijlstra
left a comment
There was a problem hiding this comment.
I'm not sure this change is an improvement. If we're going to expand the spec here, I'd rather we clearly list out some patterns that we want to require. It's going to require some work though to sort out what is reasonable to require.
| TD1(td2) | ||
|
|
||
| # invalid positional arguments | ||
| TD1({"a": 1}) # E |
There was a problem hiding this comment.
Why do we require an error? These both seem like valid calls.
There was a problem hiding this comment.
Good point — I’ve updated the conformance tests to remove the requirement for errors in those cases, since such calls can be valid and behavior may vary across type checkers.
Regarding the spec change, I’ve also simplified the wording to avoid over-specifying behavior. I agree that if we expand this area further, it would be better to clearly define specific patterns to require.
Happy to help explore and document those patterns if needed.
@JelleZijlstra
4 participants
This PR updates the TypedDict constructor specification to clarify handling of positional arguments.
The current spec states that only keyword arguments are allowed, but this does not fully reflect runtime behavior and differences across type checkers.
This change:
This aims to improve consistency while avoiding unsafe or ambiguous cases.